pp108 : Referencing Transactional and Non-Transactional Data

Referencing Transactional and Non-Transactional Data

This topic describes the referencing of transactional and non-transactional data.

By setting references between controls and models, you can automate the display of a model's data in a control. Setting a reference associates a control and a model such that data is automatically synchronized between the two. This means that you can use the control to add, delete, or modify data in the backend, and also that the data displayed in the control is automatically updated with any change in the backend data.

You can use the <control name> window to set references between a control and a model as described in the Binding Data to Controls topic. As mentioned in the topic, to bind data, you must specify a Model and give a Reference to the business object (of the model) from which data is to be displayed in the control. However, the Reference XPath to be specified differs depending on the type of data (Transactional and Non-transactional) used in the model.

Consider the structure of Transactional data (EmployeesModel) as follows:

<tuple>
    <old>
        <Employees>
            <EmployeeID>1</EmployeeID>
        </Employees>
    </old>
</tuple>

For Transactional data, you need only to specify the model name (EmployeesModel) in the Model field and the business object name (EmployeeID) in the References field of the <control name> window. The Process Platform automatically picks data from the appropriate nodes of the response. You do not need to define the complete path of the business object as the reference, as it is automatically picked from the tuple/old/Employees structure.

Also, if the same model is associated with a control and its parent control, then the control is not considered as an independent view. It is considered as part of parent control view and renders data as part of the view.

Consider the following Non-transactional data that does not follow Process Platform protocol:

<items>
    <item>
        <id/> ... </item>
    <item>
        <id/> ... </item>
</items>

In case of Non-transactional data, the data starts from the first node, in this case the <items> node. The <item> node is repetitive and contains the <id> node (business object). Values from the <id> node are displayed in a control. The first node, from which the data starts, is not considered while referencing.

For Non-transactional data, you need to specify the model name in the Model field and the complete XPath of the business object in the References field of the <control name> window. This is also true for transactional models for which the Non-transactional option is selected in the Model Properties dialog box. Also, a complex XML, which is a response that contains multiple level of nodes and comprises various data under different nodes, is also considered as Non-transactional data even if it is compliant with the Process Platform protocol.

In the above non-transactional code sample, the XPath for the Reference will be item/id.

As a special case, consider setting references on a Table control such that data is displayed under columns and each set of related data is displayed in a separate row. In this case, you can set the Model and the Reference XPath of the repetitive node (in the above sample codes, Employees and item are the repetitive nodes) on the table (parent control). Depending on the data type - Transactional and Non-transactional - you need to specify the appropriate Reference XPaths. In order to display data in a table column, specify the respective business object name (in the above sample codes, EmployeeId and id) as a Reference for the column. This displays model data in columns in the table.

Note:
Prefilling List and Select Controls also involves specifying a model from which to display data in the controls at run time. Ensure that the model used to bind data to these controlsis not the same as the model used to prefill them.

Consider another example of complex data, where the tuple (in case of Transactional data) or first node (in case of Non-transactional data) contain a set of repeating child nodes.

//complex nested transactional data
<tuple>
    <old>
        <Employees>
            <EmployeeID>1</EmployeeID>
            <EmployeeName>anna</EmployeeName>
            <Orders>
                <OrderID>1</OrderID>
                <OrderDate>03092009</OrderDate>
            </Orders>
            ...
            <Orders>
                <OrderID>5</OrderID>
                <OrderDate>03102009</OrderDate>
            </Orders>
            ...
        </Employees>
    </old>
</tuple>
 
//complex nested non-transactional data
<Employees>
    <EmployeeID>1</EmployeeID>
    <EmployeeName>anna</EmployeeName> 
    <Orders>
        <OrderID>1</OrderID>
        <OrderDate>03092009</OrderDate>
    </Orders>
    ...
    <Orders>
        <OrderID>5</OrderID>
        <OrderDate>03102009</OrderDate>
    </Orders>
    ...
</Employees>

When represented in an XForm, the interface will include controls for nodes such as EmployeeID and EmployeeName, while data from the repeating child nodes (in the above sample codes, Orders) will be represented in a paginated table. The pagination toolbar of the table can be used to navigate between records. In order to reference such child nodes, you need to provide the parent view (in the above sample codes, Employees) in the property sheet of the Table control.

Even though the data is nested, it is possible to create UI representations that are not nested. To achieve this, you can use the parent view property in the property sheet and design UI such that child views display outside parent views. For details on setting the Parent for a child view, see Binding Data to Controls.

 

Related tasks

Binding Data to Controls

Related reference

Transactional and Non-transactional Data